Hotfix Changelog — Noisefloor Freeze on Older Firmware#175
Conversation
There was a problem hiding this comment.
Pull request overview
This hotfix addresses an app freeze issue when attempting noisefloor collection on MeshCore companion firmware versions older than 1.11.0. The PR implements a firmware capability gate that parses the device's firmware version from its model string and only attempts noisefloor collection for firmware v1.11.0 or newer (nightly builds are assumed to support the feature). A 5-second timeout is added as a safety fallback to prevent indefinite waits if the device fails to respond.
Changes:
- Added firmware version parsing from device model strings with regex pattern matching
- Implemented capability gate to conditionally enable noisefloor collection based on firmware version
- Added 5-second timeout to both initial and periodic radio stats requests
- Enhanced error logging and UI feedback for unsupported firmware versions
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
docs/CONNECTION_WORKFLOW.md |
Documents the firmware version parsing logic, capability gate behavior, and UI/error handling for unsupported firmware |
content/wardrive.js |
Adds firmware version parsing functions, implements capability gate in connection flow, adds timeout to radio stats requests, and enhances error logging |
| } else { | ||
| debugWarn(`[BLE] getRadioStats failed on connect: ${e && e.message ? e.message : String(e)}`); | ||
| } | ||
| state.lastNoiseFloor = null; // Show '-' instead of 'ERR' for unsupported feature |
There was a problem hiding this comment.
The comment states "Show '-' instead of 'ERR' for unsupported feature" but the actual UI behavior (in setConnStatus at line 1208) displays "Firmware 1.11+" when state.lastNoiseFloor is null, not "-". The comment should be updated to reflect the actual UI behavior.
| state.lastNoiseFloor = null; // Show '-' instead of 'ERR' for unsupported feature | |
| state.lastNoiseFloor = null; // Flag as unsupported so UI shows "Firmware 1.11+" instead of "ERR" |
| debugLog("[BLE] Started periodic noise floor updates (5s interval)"); | ||
| } else { | ||
| debugWarn(`[BLE] getRadioStats failed on connect: ${e && e.message ? e.message : String(e)}`); | ||
| debugLog("[BLE] Noise floor updates not started (feature unsupported by firmware)"); |
There was a problem hiding this comment.
The debug log message is misleading when the initial radio stats request fails. At this point, we already know the firmware supports noisefloor (checked at line 5828), so the message "feature unsupported by firmware" at line 5857 is inaccurate. It should indicate that the initial request failed, not that the feature is unsupported. Consider changing the message to something like "Noise floor updates not started (initial request failed)" to avoid confusion during debugging.
| debugLog("[BLE] Noise floor updates not started (feature unsupported by firmware)"); | |
| debugLog("[BLE] Noise floor updates not started (initial request failed)"); |
| - Stores noise floor in `state.lastNoiseFloor` | ||
| - Connection bar displays `🔊 <value>dBm` | ||
| - Starts periodic 5-second updates via `startNoiseFloorUpdates()` |
There was a problem hiding this comment.
The documentation implies that periodic updates are always started when firmware supports noisefloor, but the implementation only starts them if the initial radio stats request succeeds. Consider adding a clarification that periodic updates are only started if the initial request returns a valid noisefloor value. For example: "Starts periodic 5-second updates via startNoiseFloorUpdates() if initial request succeeds"
| - Stores noise floor in `state.lastNoiseFloor` | |
| - Connection bar displays `🔊 <value>dBm` | |
| - Starts periodic 5-second updates via `startNoiseFloorUpdates()` | |
| - **If initial request succeeds and returns a valid noisefloor value**: | |
| - Stores noise floor in `state.lastNoiseFloor` | |
| - Connection bar displays `🔊 <value>dBm` | |
| - Starts periodic 5-second updates via `startNoiseFloorUpdates()` | |
| - **If initial request fails or returns no valid noisefloor**: | |
| - Periodic noise floor updates are **not** started | |
| - Connection continues without noise floor display/updates |
| - **If not supported** (< 1.11.0): | ||
| - Skips `getRadioStats()` call entirely (prevents app freeze) | ||
| - Sets `state.lastNoiseFloor = null` | ||
| - Connection bar displays `🔊 -` |
There was a problem hiding this comment.
The documentation states the connection bar displays "🔊 -" when noisefloor is not supported, but the actual UI implementation (setConnStatus function at line 1208) displays "🔊 Firmware 1.11+" when state.lastNoiseFloor is null. The documentation should be updated to reflect the actual UI behavior.
| - Connection bar displays `🔊 -` | |
| - Connection bar displays `🔊 Firmware 1.11+` |
Fixed
Prevented app freeze when noisefloor collection is attempted on MeshCore companion firmware < 1.11.0.
Added a firmware capability gate: noisefloor collection is only enabled when device firmware is v1.11.0+ (parsed from the device-reported model string). Nightly builds are treated as supported.
Improved
Added a 5s timeout safety fallback to noisefloor/radio stats requests to avoid indefinite waits even if a device fails to respond.
UI / Logging
When noisefloor is unsupported, the UI shows “-” for noisefloor and an entry is added to the Error Log indicating noisefloor requires 1.11.0+.